iT邦幫忙

2021 iThome 鐵人賽

DAY 22
2
Software Development

用Keycloak學習身份驗證與授權系列 第 22

Day21 - 【概念篇】在Flow這段小旅途外的風景

  • 分享至 

  • xImage
  •  

本系列文之後也會置於個人網站


在這一小段路中介紹了Password Flow、Implicit Flow、Code Flow、Refresh Token Flow、Client Credentials Flow、PKCE、Device Code Flow。有些模式已經被發現可能有潛在風險,有些模式無法單獨使用。這或許還不是全部,至少到現在為止都還沒有提到過金融級應用Flow--CIBA。

Client Initiated Backchannel Authentication Profile(CIBA)

本小節也不會詳細介紹CIBA(Client Initiated Backchannel Authentication)。儘管CIBA現在階段還只是草案(Draft),但在Keycloak v15版本中已經可以使用。大概也已經確實有一些應用使用。

為什麼你不該繼續使用Implicit Flow?

在談到Implicit Flow時候,提到過:

將存取權杖暴露在使用者面前也不是非常好的做法

所以通常在處理完存取權杖後,應該會跳轉畫面,或至少將資訊清除。在網址列上的權杖(token)簡直不要太好取得:

window.location.hash

簡單一行就可以取得基礎,再做一些分析就可以輕易得到存取權杖。儘管在「Quick Start」的Web App中取得的是id_token,但access_token也是同樣。

但爲了讓客戶端處理,這是不得已選項。要是根本無法取得,就算走標準的code flow也沒法玩下去。但主要防範的不是坐在電腦前開著瀏覽器的資源擁有者,要注意的是注入風險。也就是XSS跨站腳本攻擊。

就算不是隱含模式,也很有可能有跳轉頁面的需求。在跳轉頁面後網址列上的token自然也就消失了。爲了讓跳轉的頁面能夠知道存取權杖,在跳轉前有可能將存取權杖儲存在localStorage或是sessionStorage

但存localStorage或是sessionStorage是不是就是安全的?我沒有答案。同樣XSS攻擊也可以很容易的取得localStorage或是sessionStorage裡的資料。但或許可以使用特別的key,降低被猜測到取得的風險。

可以存取「歷史記錄」的擴充套件

XSS跨站腳本攻擊是不得不多加注意的風險外,其實隱含模式的風險增加也與越發強大的瀏覽器有關。或者說與越發多樣的瀏覽器擴充套件,與多樣的使用環境有關。

XSS跨站腳本攻擊在某種程度上還可以透過開發人員多加留意防範。但使用者使用什麼瀏覽器,又安裝了什麼擴充套件就不是開發人員可以輕易處理的風險了。

通常而言,window.hisory相關的API會限制腳本存取瀏覽器歷史記錄的能力,但是給瀏覽器擴充套件的API - WebExtensions API -- history就強大許多。

下面的擴充套件只說明擴充套件確實有可能取得歷史記錄,不代表存在問題。甚至有些設計的我還覺得蠻方便的

Improved History

History Master

也就是說明就算頁面跳轉了,惡意的瀏覽器擴充套件仍有可能透過歷史記錄找到存取權杖。使用擴充套件的風險遠不止這樣,類XSS攻擊的風險同樣存在,甚至可能更多風險。所以在使用時,應該同時留意使用了什麼瀏覽器,啓用了什麼擴充套件。

小節結語

OAuth的內容可能遠不止本系列提到的這麼多,未來還有可能再增加、改版。有些概念很遺憾我也沒有很好的理解,只能夠以額外的形式做一點補充。

接著會是稍微簡單一點,與keycloak有關的內容。在那之後,才會在提到Open-Id,這個可能經常與OAuth一起看到的名詞。

參考資料


上一篇
Day20 - 【概念篇】OAuth flows: Device Code(2)
下一篇
Day22 - 【概念篇】Keycloak使用基本概念 - 前導
系列文
用Keycloak學習身份驗證與授權41
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言